1. Field of the Invention
The invention relates generally to operating system stability and security, and specifically to the isolation of device drivers within a computer system,
2. Description of Background Art
It is recognized in the field of computer science that device drivers are a weak link in the systems and methods designed to ensure computer system stability and security. Because device drivers frequently interact with hardware, they are typically designed to execute with special execution privilege levels not normally afforded to applications. In fact, in many operating systems, device drivers execute on the same execution privilege level as the operating system kernel itself. Executing a device driver with a special execution privilege level introduces the possibility that the device driver may not be subject to the security policies and fault protections that ordinarily protect the computer system. Device drivers, either through error or malicious intent on the part of their designer, can seriously compromise the trustworthiness of the computer system on which they are executed. Furthermore, because different device drivers are typically designed for various kinds of hardware, a large number of device drivers are available. The sheer volume of device drivers makes consistent quality control a challenge, and yet in many operating systems a single device driver can undermine the rigorous quality control invested in the operating systems.
One possible approach to the device driver stability problem is to redesign device drivers to execute without special execution privilege levels. Device drivers would execute with the same (or similar) execution privilege level as user applications, and therefore would be subject to the operating system precautions normally taken for user applications. However, the tradition of privileged device driver execution is well-established in device driver design, and the canon of legacy device drivers that would need to be rewritten is enormous. Therefore, even if all device drivers could be successfully rewritten as unprivileged applications, this approach would be extremely costly and largely impractical.
Another possible approach is to execute each device driver in a separate virtual memory address space, providing the ability to limit the memory addresses to which a device driver is capable of writing. However, the driver nonetheless has the ability to execute instructions with a special execution privilege level, set special registers, and access input/output devices. Therefore, a maliciously or improperly designed device driver can cause harm to the computer system despite the separate virtual address space. Thus executing a device driver in a separate virtual memory address space is, by itself, an insufficient solution.
Some have suggested isolating device drivers in distinct, software-implemented “virtual machines” (see below). In this approach, a full computer system is software-virtualized to execute the device driver, an operating system and guest applications.
Executing a device driver in a separate virtual machine can provide some protection against malignant actions by the device driver, but this protection comes with considerable cost in terms of processing and storage overheads. A virtual machine must be scheduled and serviced for each isolated device driver. The virtual machine abstraction reduces the performance of the guest applications and the device driver. As the number of isolated drivers increases, the performance loss increases.
Therefore, what is needed is a technique for efficiently isolating device drivers without the need to rewrite existing device driver code.